Business Intelligence (BI) generally refers to software tools used to improve business enterprise decision-making. These tools are commonly applied to financial, human resource, marketing, sales, customer and supplier analyses. More specifically, these tools can include: reporting and analysis tools to present information, content delivery infrastructure systems for delivery and management of reports and analytics, data warehousing systems for cleansing and consolidating information from disparate sources, and data management systems, such as relational databases or On Line Analytic Processing (OLAP) systems used to collect, store, and manage raw data.
A subset of business intelligence tools are report generation tools. There are a number of commercially available products to produce reports from stored data. For instance, Business Objects Americas of San Jose, Calif., sells a number of widely used report generation products, including Crystal Reports™, Business Objects OLAP Intelligence™, Business Objects Web Intelligence™, and Business Objects Enterprise™. As used herein, the term report refers to information automatically retrieved (i.e., in response to computer executable instructions) from a data source (e.g., a database, a data warehouse, a plurality of reports, and the like), where the information is structured in accordance with a report schema that specifies the form in which the information should be presented. A non-report is an electronic document that is constructed without the automatic retrieval of information from a data source. Examples of non-report electronic documents include typical business application documents, such as a word processor document, a presentation document, and the like.
A report document specifies how to access data and format it. A report document where the content does not include external data, either saved within the report or accessed live, is a template document for a report rather than a report document. Unlike other non-report documents that may optionally import external data within a document, a report document by design is primarily a medium for accessing and formatting, transforming or presenting external data.
A report is specifically designed to facilitate working with external data sources. In addition to information regarding external data source connection drivers, the report may specify advanced filtering of data, information for combining data from different external data sources, information for updating join structures and relationships in report data, and logic to support a more complex internal data model (that may include additional constraints, relationships, and metadata).
In contrast to a spreadsheet, a report is generally not limited to a table structure but can support a range of structures, such as sections, cross-tables, synchronized tables, sub-reports, hybrid charts, and the like. A report is designed primarily to support imported external data, whereas a spreadsheet equally facilitates manually entered data and imported data. In both cases, a spreadsheet applies a spatial logic that is based on the table cell layout within the spreadsheet in order to interpret data and perform calculations on the data. In contrast, a report is not limited to logic that is based on the display of the data, but rather can interpret the data and perform calculations based on the original (or a redefined) data structure and meaning of the imported data. The report may also interpret the data and perform calculations based on pre-existing relationships between elements of imported data. Spreadsheets generally work within a looping calculation model, whereas a report may support a range of calculation models. Although there may be an overlap in the function of a spreadsheet document and a report document, these documents express different assumptions concerning the existence of an external data source and different logical approaches to interpreting and manipulating imported data.
In normal operation, a report server accesses a data source and launches a query to retrieve data for a report. The report is processed and formatted per the schema that defines the report. In this way, data is pulled from a data source and is placed in a report. Normally, a report server does not treat the data stored in composite objects as a data source for reporting purposes. In accordance with the object oriented paradigm, an application programmer creates an application comprising a collection of individual objects that may act on themselves and each other. This is in contrast to a traditional model in which an application operates as a collection of functions. In designing an object oriented program, a computer programmer produces objects that enable the requirements of the application If reporting is a requirement, the programmer must engage in a lot of activity to produce a report. Further, application programmers do not normally concern themselves with working with data structures that are distinguished by the ease in which they can become data sources for a report server. For example, an application programmer could be working with legacy code that includes a collection of objects designed with no reporting function in mind. However, the application programmer, possibly to satisfy new requirements, may now need to implement a reporting function with the collection of objects as a data source.
A remedy to relieve the application programmer's burden is an application programming interface (API), which provides the application programmer with access to reporting capabilities. However, the API may create a disincentive to the application programmer to create an object that makes a good source for report data. Accordingly, it would be desirable to provide an API that facilitates reporting off objects created by application programmers.